home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
inet
/
ietf
/
rdisc
/
90jul.min
< prev
next >
Wrap
Text File
|
1993-02-17
|
7KB
|
179 lines
CURRENT_MEETING_REPORT_
Reported by Steve Deering/Stanford
RDISC Minutes
Agenda
o Draft Specification
- comments?
- disposition?
o Implementations
o Black-Hole Detection
This was the fourth meeting of the Router Discovery Working Group.
The first and dominant item on the agenda was a discussion of the (late)
July draft of the ICMP router discovery specification. The following
improvements and changes were agreed upon:
o Add a few sentences emphasizing that this is NOT a routing protocol
-- hosts are expected to rely on Redirects for finding the ``best''
first-hop router for any given destination.
o Make it even clearer than it already is that hosts must NOT
continuously send solicitations.
o Add a note explaining that, even though the timing values are
defined or configured in units of seconds, randomized intervals
should be computed at the best available resolution of the system's
interval timer.
o Fill in the missing ICMP Type values with officially-allocated
numbers.
o Change MAX_RESPONSE_DELAY from 5 seconds to 2 seconds.
o Change the upper bound on MaxAdvertisementInterval from (2^16 - 1)
to 1800 seconds (30 minutes).
o Even when a router is configured to use multicast instead of
broadcast, it may respond to a broadcast solicitation with a
broadcast advertisement (if not a unicast advertisement).
o When a router performs a graceful shutdown, it should send out
advertisements with a lifetime of 0, to flush its addresses from
the hosts' router lists.
There was also discussion of adding an authentication field to the
Router Advertisement message. Deering argued that such a field could be
appended to the existing message format if and when a non-null
authentication type is defined for router discovery (i.e., the absence
of an authentication field indicates ``null'' authentication.) Noel
Chiappa was not very happy with this proposal, but said he would check
it out with the security gurus [which he subsequently did; apparently,
Deering's proposed scheme will be acceptable].
1
The group then agreed that, with the above modifications, the draft
specification was ready to enter into the Internet standardization
track. Chiappa explained the necessary steps, as follows:
o Update the specification to incorporate the agreed changes and make
it available as an Internet Draft as soon as possible.
o After a one month comment period as an Internet Draft, if no
significant problems are uncovered, submit it to the IESG with the
group's recommendation that it be published as a Proposed Standard.
o Operational experience with multiple, independently-developed
implementations is generally required for advancement beyond
Proposed Standard status. The decision to advance to the next
stage (Draft Standard) is up to the IAB, with advice from the IESG.
That led to the next topic on the agenda: implementations. Andy
Cherenson and Deering confirmed their previous commitment to generate an
implementation of the protocol to run in user space on 4.3BSD and
derived systems, perhaps starting from the source code for cisco's GDP
demon; the implementation will include both the host and the router
parts of the protocol. John Veizades volunteered to do a Macintosh
implementation of the host part of the protocol, and said he had an
environment for testing the protocol's behavior under the simultaneous
startup scenario (a rack of Macs on a single power circuit).
Implementations for other platforms, and at the kernel level in BSD,
were solicited, but no promises were made. The importance of getting
the major router vendors to implement the router part of the protocol
and make it available for user testing was recognized; group members
were encouraged to make that desire known to their favorite router
vendors.
We then concluded that no further meetings of the Router Discovery
Working Group would be necessary, if all goes according to plan.
(Yah!!) We discussed the possibility of transforming into a ``Black
Hole Detection'' Working Group, and decided not to do so. A document
addressing the wider issue of host routing, of which black hole
detection is a part, would be very valuable, but there was little
enthusiasm for forming a new Working Group for that purpose; it might be
taken up by the next incarnation of the Host Requirements Working Group,
or perhaps some individual(s) will generate a document recommending (but
not standardizing) good host routing strategies.
ACTION ITEMS
o Deering: Ask the Internet Assigned Numbers Authority for two new
ICMP Types.
o Deering: Revise the specification as agreed at this meeting and
submit it as an Internet Draft. If no substantive, negative
comments are received during a one month comment period, recommend
the specification to the IESG as a Proposed Standard.
o Deering and Cherenson: Implement both the host and router parts of
2
the protocol as a user-level demon for 4.3BSD-derived systems, and
make it available to the Working Group and the wider internet
community for testing and validation of the protocol.
o Veizades: Implement the host part of the protocol for Macintosh
and test it in an environment with many hosts on the same subnet
(especially under the simultaneous startup scenario).
o Everyone: Encourage your favorite router vendor to do a prototype
implementation of the protocol, for in-house and customer- site
testing.
Attendees
Zorica Avramovic zorica@sparta.com
Art Berggreen art@opal.acc.com
Larry Brandt lbrandt@sparta.com
Eric Brunner brunner@monet.berkeley.edu
Andrew Cherenson arc@sgi.com
Steve Deering deering@pescadero.stanford.edu
Robert Elz kre@munnari.oz.au
Karen Frisa karen@kinetics.com
Robert Gilligan gilligan@sun.com
Tony Hain alh@eagle.es.net
Steven Hubert hubert@cac.washington.edu
Ole Jacobsen ole@csli.stanford.edu
Ken Jones uunet!konkord!ksj
Michael Karels karels@berkeley.edu
Stev Knowles stev@ftp.com
Alex Koifman akoifman@bbn.com
Sam Lam
Gregory Lauer glauer@bbn.com
John Lekashman lekash@orville.nas.nasa.gov
Solomon Liou solomon%penril@uunet.uu.net
Yoni Malachi malachi@polya.stanford.edu
Tony Mason mason@transarc.com
Paul McKenney mckenney@sri.com
John Moy jmoy@proteon.com
John Mullen
Stephanie Price cmcvax!price@hub.ucsb.edu
Tim Seaver tas@mcnc.org
Deepinder Sidhu sidhu@umbc3.umbc.edu
Craig Smelser
Frank Solensky solensky@interlan.interlan.com
Martha Steenstrup msteenst@bbn.com
Zaw-Sing Su zsu@tsca.istc.sri.com
Paul Tsuchiya tsuchiya@thumper.bellcore.com
John Veizades veizades@apple.com
Carol Ward cward@spot.colorado.edu
Jonathan Wenocur jhw@shiva.com
Walter Wimer ww0n+@andrew.cmu.edu
3